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REMARKS/ARGUMENTS 

Claims 42, 42, 50, 51 , 55, 56, 59, 60, 65 and 68 Stand rejection under 35 U.S.C. 
§ 1 12 2 na Paragraph for the following reason, the term "match" Is not defined by 
the claims, the specification does not provide a standard for ascertaining the 
requisite degree or context of said "match". Applicants traverse this grounds of 
rejection. 

Applicant's specification defines "match" as the matching of names and other 
personal data, e.g. biometrics - fingerprints, etc. One embodiment In the current 
application teaches the screening of individuals against watch lists prior to 
boarding an airplane, or prior to employment. Such a screening can be a simple 
text-based "matching" of names and other personal data, especially, biometrics 
like fingerprint minutiae or features of the human face, see paragraph 4. The 
current specification further defines "match" within an embodiment of the current 
application by using a contract 601 . Specifically disclosed and claimed is a 
contract that defines the service processing steps of matching, see paragraphs 
95-104 of the specification. Accordingly, applicants believe that the pending 
claims are clear and distinct to overcome the rejection under 35 U.S.C. § 1 12 2 
Paragraph. 

Claims 1 - 68 stand rejected under 35 U.S.C. § 102(b) as being anticipated by 
Schneier et al. U.S. Patent 6,099,408 (hereafter referred too as Schneier). 
Applicants traverse this grounds of rejection for the following reasons. 

Schneier has at the core technology the use of "random numbers" to ensure the 
confident exchange of information with keys, see the abstract, Figures 2, 3, 5, 6, 
7, 8, 9, 10 and 1 1 - 18. The only feature that Schneier teaches that appears to 
be similar, in wording only, to applicants' claimed invention is the disclosure of 
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cryptographic processors 210 and 310. However, Schneler's cryptographic 
processor is only used for transmitting a set of random numbers and encryption 
keys to and from game players in a gaming system, see column 2, lines 4-35. 
No where in Schneier is there a teaching that a "contract" is used as claimed in 
applicants' claims, and as required under 35 U.S.C. § 102(b). Furthermore there 
are no suggestions in Schneier to include additional elements that address the 
additional elements of the applicants' claimed invention. The inclusion of these 
additional claimed features would teach away from the teachings of the Schneier 
patent. The storing of a player data, such as name, social security number, 
credit card number and the public/private encryption keys (see column 5. lines 1 1 
- 16) does not teach or suggest applicants' claimed invention of requiring 
".. ..uploading said service specificat ion into said secure computation 
environment: enforcing said service specification with regards to all cooperating 
parties; 

Another fundamental difference between Schneier and applicants' claimed 
invention is that the subject being "matched" does not have access to the 
system. The underlying feature of Schneier is to allow the "player" access to the 
gaming system to conduct wages, see column 14, line 59 - column 16, line 55. 

It is noted the examiner stated that a "suggestive" reading of Schneier implies 
that applicants' claimed service specification is taught. Again, applicants 
traverses this point because applicants' service specification involves the 
Interaction between parties whereas Schneier seeks to prevent any interaction 
between parties, see column 7, line 46 - column 8, line 24. Nor does Schneier 
teach or suggest an "... enforcing said service specifica tion with regards to all 
cooperating parties ..." as required by applicants' claims. 

In addition, the Examiner further suggests that random number information 
associated with a player is also part of the service specification as claimed by 
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applicants. This is completely in error. Applicants' claimed service specification 
is required to "....identify cooperating parties". "...Identify a reque stor and format 
a service request" . ".. .validating the actual requestor and thQ content of the 
service request against an expected requestor and expected conten ts as defined 
in the service specification": and ... "executing the conditional proce ssing and the 
notifications as defined In the service specification." None of these claimed 
features are taught or suggested by Schneier. It is clear that applicants' claimed 
service specification includes more collective limitations that are not taught or 
suggested by the single aspects of Schneier. 

Schneier further fails to teach or suggest applicants claimed secure computation 
environment in a host system, where the ".. , service specification (loaded^ into 
said secure computation environment" . The Examiner's suggestion "whereas the 
setup of players selection / authentication, on a per player per se, and multiple 
player embodiment insofar as the clients and servers clearly have the same rules 
and all associated information required to play" is also incorrect. Applicants' 
claimed service specification controls the host system not vice versa. Schneier 
would fail to function if a third party dictated the rules of game play. Applicants' 
invention requires a host system receiving the claimed service specification or 
"contract" to function based on the contract. 

The Examiner further suggests that the game player is both the "individual" and 
the "requester". Again, this teaches away from applicants' claimed invention 
which requires " .. .identify a requestor and format of a service request, said 
request is adapted to contain info rmation about an individual". 

Applicants' claimed invention further requires "...a machine interpretable 
contract" as claimed in claims 33, 37, 40 and 41 . Schneier fails to teach or 
suggest "...a machine interpretable contract be tween all parties, which would 
cooperate with a particular applicat ion running on said host computer; 
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uploadinojsaid contract into said secure computation envifonrneat; 
enforcing said contract with regards to all cooperating parties: " 

Applicants' claimed invention further requires either "...at least one contract for 
governing a service between a service provider, a client and at least one other 
party..." or "....a contract ID for any contract that governs a service between the 
service provider, the client and the at least one other party." Schneier fails to 
teach a contract or a contract ID for governing a service, for matching 
identification, involving a service provider, a client and at least one other party. 
Regarding the Examiner's assertion that clients can pass information between 
themselves in the gaming environment of Schneier, this feature is not seen by 
applicants. What Schneier clearly teaches is that there is "no" interaction among 
other clients, see column 7, line 46 - column 8, line 24. 

While the Examiner has broadly interpreted the claims of the present invention, 
the desired effect has failed to produce the elements as required by applicants 1 
claims. In addition, the overall teachings of Schneier teaches away from the 
present claimed invention. Applicants believes that Schneier is non-analogous 
prior art, both from a presently claimed invention and from the subject matter of 
applicants' specification. 

Accordingly, applicants believe that claims 1 -68 are not anticipated nor made 
obvious by Schneier et al. U.S. Patent 6,099,408. But are in fact in condition for 
allowance and the application should be allowed to issue. 
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Please charge any fee necessary to enter this paper and any previous paper to 
deposit account 09-0468. 



IBM Corporation 

Intellectual Property Law Department 
1101 Kitchawan Road 
Route 134 
P. O. Box 218 

Yorktown Heights, New York 10598 
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